Product development projects typically require significant effort to monitor and manage. Furthermore, computer software development projects are inherently difficult to manage. This difficulty is partly due to the large number of tasks and associated deliverables that comprise a software package and the vastness of paperwork and project files associated with these tasks and deliverables. Another contributing factor are the complex interdependencies established between individual tasks and deliverables during the development cycle of a software package. Yet another contributing factor is the need to generate and maintain a design specification associated with the software being developed.
Management of development projects typically includes organizing, maintaining, and controlling access to project documents, schedules, and the like. Furthermore, there are often multiple development projects occurring concurrently within an enterprise organization, thus significantly expanding the document management efforts. Historically, management of a master project schedule entails, among other tasks, manually entering data into a scheduling application, manually creating links between schedules, and manually aggregating individual developers' task schedules into the master project schedule. These are cumbersome and error-prone tasks, with little to no oversight and quality control.
A master project schedule is often in a state of flux, whereby management solicits the developers for task statuses and related schedule updates. Often, the feedback provided to management by the developers has little oversight and is not according to a rigid policy, procedure, or validation process. Thus, the actual status of a project schedule is often difficult to ascertain since the progress of individual tasks are dictated by subjective, and often self-supporting, progress reports by those individuals that are assigned to the task.
For example, some scheduling systems allow a developer to signify that a task is partially completed, i.e., ninety percent completed. This information is then entered into the scheduling system to determine whether the project is on-schedule. However, because there is generally no accountability as to whether an individual's status is reliable, the current process of obtaining project status tends to shadow the realistic progress of the project.
In view of the foregoing, there is a clear need for a technique for management of interdependent development project task schedules that reduces the manual tasks related thereto.
Furthermore, during the development of software, generating and maintaining accurate and consistent design specifications is a challenge. Sometimes variable names are misspelled or used inconsistently within the design specification and often these errors go undetected in the inspection process. Furthermore, sometimes variable names referenced in a design specification are inconsistent with organization rules, constraints and processes, such as variable naming rules.
If a design specification contains incorrect or inconsistent variable names that go undetected during the document inspection process, then these errors are usually detected by a compiler when the software code associated with the specification is compiled. In such a scenario, time and resources are wasted in correcting the errors, both in the code and in the design specification. In some organizations, design specifications must also abide by the organization's document change control process. Thus, the wasting of resources is exacerbated because a revised specification document requires generation of a document change request and further inspection of the document and the change request, which presents additional costs and results in additional wasting of resources. In view of the foregoing, there is a clear need for an automated technique for checking and verifying the accuracy and consistency of a software design specification document. For example, there is a need for validating various aspects of a class specification.